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Foreword 



This Technical Specification (TS) has been produced by ETSI Project Telecommunications and Internet Protocol 
Harmonization Over Networks (TIPHON). 

The present document is part 3 of a multi-part deliverable covering Telecommunications and Internet Protocol 
Harmonization Over Networks (TIPHON) Release 3; Functional Entities, Reference Points and Information Flow 
Definitions, as identified below: 

TR 101 329-1: "General aspects of Quality of Service (QoS)"; 

TS 101 329-2: "Definition of Quality of Service (QoS) Classes"; 

TS 101 329-3: "Signalling and Control of end-to-end Quality of Service"; 

TS 101 329-4: "Quality of Service Management"; 

TS 101 329-5: "Quality of Service (QoS) measurement methodologies"; 

TR 101 329-6: "Actual measurements of network and terminal characteristics and Performance parameters in 
TIPHON networks and their influence on voice quality"; 

TR 101 329-7: "Design Guide for elements of a TIPHON connection from an end-to-end speech transmission 
performance point of view"; 

TR 101 329-8: "QoS of multimedia services in TIPHON systems"; 

TS 101 329-9: "Call performance Classification". 
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Introduction 



The present document forms one of a series of technical reports and technical specifications by TIPHON Working 
Group 5 addressing aspects of Quality of Service (QoS) in TIPHON systems. These documents are all part of a single 
document TS 101 329, the structure of which is illustrated in figure 1. 
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Figure 1: TIPHON QoS document structure 

The present document, describes a framework for the signalling and control of end-to-end Quality of Service in 
TIPHON Systems. 
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Scope 



The present document describes a framework for enabling the end-to-end QoS levels defined in TS 101 329-2 [1] to be 
signalled and controlled in TIPHON systems. The mechanisms involved operate between TIPHON terminals, IP 
telephony Service Providers (ITSPs), and network transport systems, and provide a flexible means for the dynamic 
allocation of QoS parameters across these entities in order to meet the QoS Service Classes defined in TS 101 329-2 [1]. 
The functional entities involved in the QoS signalling and control are defined, as are the requirements of the reference 
points between these functional entities. The QoS parameters and information flows used to establish the required 
Service QoS levels are also specified. 

The Application Plane mechanisms described in the present document are intended to be independent of the transport 
QoS mechanisms used within the underlying IP networks. 

The emphasis of the present document is on media QoS (primarily voice, but the mechanisms are also applicable to 
other media types). Issues related to performance of the signalling channels are outside the scope of the present 
document. 

TS 101 314 [2] describes how this QoS framework fits into the overall TIPHON architecture and details of the 
signalling involved are described in TS 101 471 [3]. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 



• 



For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

[1] ETSI TS 101 329-2: " TIPHON Release 3; End-to-end Quality of Service in TIPHON Systems; 

Part 2: Definition of Quality of Service (QoS) Classes" 

[2] ETSI TS 101 314: "Telecommunications and Internet Protocol Harmonization Over Networks 

(TIPHON); Network architecture and reference configurations; TIPHON Release 2. " 

[3] ETSI TS 101 471: "Telecommunications and Internet Protocol Harmonization Over Networks 

(TIPHON); Signalling for calls between H.323 terminals and terminals in a Switched-Circuit 
Network (SCN); Phase III: Scenarios 1, 2, 3, and 4". 



Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

IP Telephony Service Provider (ITSP): Service Provider providing IP Telephony Services 

NOTE: The same business entity may act as both a Transport Network Operator and an IP Telephony Service 
Provider. 

Interconnect Function (ICF): functional entity that interconnects Transport Domains. It provides a policy and/or 
administrative boundary and may police authorized media flows between two Transport Domains to ensure they are 
consistent with the QoS policy specified by the relevant Transport Resource Manager 
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Quality of Service Manager (QoSM): functional entity that mediates requests for end-to-end QoS in accordance with 
policy determined by the QoSPE. It communicates with, other QoSMs and with TRMs to determine, establish and 
control the offered QoS 

Quality of Service Policy Element (QoSPE): functional entity that manages IP Telephony QoS policies and provides 
authorization of permitted and default QoS levels. It receives requests from and issues responses to QoSMs to establish 
the authorized end-to-end QoS levels 

Service Domain: collection of physical or functional entities offering IP telephony services under the control of an IP 
Telephony Service Provider which share a consistent set of policies and common technologies 

Transport Domain (TD): collection of transport resources sharing a common set of policies, QoS mechanisms and 
transport technologies under the control of a Transport Network Operator 

Transport Network: collection of transport resources which provide transport functionality 

Transport Network Operator: business entity operating a Transport Network 

Transport Policy Entity (TPE): functional entity that maintains the policies of a Transport Domain 

Transport Resource Manager (TRM): functional entity that applies a set of policies and mechanisms to a set of 
transport resources to ensure that those resources are allocated such that they are sufficient to enable QoS guarantees 
across the domain of control of the TRM 

Transport Function (TF): functional entity representing the collection of transport resources within a Transport 
Domain which are capable of control by a Transport Resource Manager 

User Equipment (UE): equipment under the control of an End-User 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

ATM Asynchronous Transfer Mode 

BC Bearer Control 

CBR Constant Bit Rate 

DiffServ Differentiated Services 

FEC Forward Error Correction 

ICF Interconnect Function 

IntServ Integrated Services 

IP Internet Protocol 

ITSP IP Telephony Service Provider 

MPLS Multi Protocol Label Switching 

QoS Quality of Service 

QoSM Quality of Service Manager 

QoSPE Quality of Service Policy Element 

RMS Root Mean Square 

RSVP Resource Reservation Set-up Protocol 

RTP Real-time Transport Protocol 

SCN Switched Communications Network 

SLA Service Level Agreement 

TD Transport Domain 

TF Transport Function 

TPE Transport Policy Element 

TRM Transport Resource Manager 

UDP User Datagram Protocol 

UE User Equipment 

VBR Variable Bit Rate 

VPN Virtual Private Network 
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Void 



QoS Architecture 



5.1 



TIPHON Architectural Planes 



The Generalized TIPHON Architecture is shown in figure 2 (see TS 101 314 [2]). 




Figure 2: Generalized TIPIHON Architecture 

End-to-end QoS signalling and control will in general involve QoS information flows in each of the architectural 
planes. 

The Required end-to-end QoS levels are established within the IP Telephony Application Plane between End-Users and 
Service Provider(s). Decisions determining QoS, specific to the application, will take place in the IP Telephony 
Application Plane (e.g. codec type, packetization, etc). 

The IP Transport Plane (IP Network Operators) provides a QoS service to the Application Plane (Service Providers). 
QoS control within the IP Transport Plane is the responsibility of the IP Network Operators. 



5.1 .1 IP Telephony Application Plane 



Within this plane, QoS parameters specific to the application are requested, authorized, signalled, controlled and 
accounted. 



5.1 .2 IP Transport Plane 

Within this plane, general non-application specific parameters effecting QoS must be controlled and accounted to 
achieve the QoS requirements requested by the application. 

5.1.3 Management Plane 

Within this plane QoS management entities applicable to both application and transport planes will reside and 
information flows applicable to QoS management will terminate. 



ETSI 



10 ETSI TS 101 329-3 V2.1.1 (2001-09) 

5.2 Service and Transport Domains 

A TIPHON-compliant deployment will in the general case be made up of a number of separate Service and End-User 
Domains, each representing the domain of control of an ITSP or End-User. These domains will generally be restricted 
to IP Telephony Application plane functionality, e.g. gatekeepers, softswitches, call agents, etc. 

Similarly, a TIPHON-compliant system will, in general, also be made up of a number of separate Transport Domains. 
Transport Domains consist solely of transport related functionality; this includes IP routers and switches, firewalls, etc. 
Each Transport Domain may have its own QoS policies and/or differ from other domains in terms of administrative 
control (e.g. Network Operator), QoS mechanisms (RSVP/IntServ, DiffServ, MPLS), access, metering, addressing 
schemes (global, local) and transport protocol (IPv4, IPv6), etc. 

Since these policies are local, functional entities are needed to interface to other domains. These entities are called 
Interconnect Functions. 

The general TIPHON deployment is illustrated in figure 3. 

5.2.1 Void 

5.2.2 Void 

5.2.3 End-to-end QoS Control 

End-to-end QoS control across multiple domains may be achieved in one of two ways: 

• by having an IP Telephony Application Service Domain control each Transport Domain. The Service 
Domain would request the transport resources with QoS from each of the Transport Domains and 
establish the interconnect in a controlled fashion; 

• by means of end-to-end signalling within and between Transport Domains which share common 
policies. 

These two mechanisms are explained below. 

5.2.3.1 IP Application Plane control 

In this first case, the routing of the call between Transport Domains is under the control of the ITSPs. In this general 
case, where the Transport Plane is made up of a number of heterogeneous Transport Domains, each domain may have 
its own QoS mechanisms and policies. 

Figure 3 illustrates the general case where a number of separate ITSPs and Transport Domains are involved in a call. 

Call-Control signalling takes place in the IP Telephony Application Plane between ITSPs and between End-Users & 
ITSPs. 

Transport flows are between End-Users & Transport Domains and between Transport Domains. 

QoS signalling and SLAs are between End-Users & ITSPs and between ITSPs and follow Call Routing. Between each 
ITSP involved in the call and its associated Transport Domain(s) QoS SLAs then ensure that the required QoS 
parameters are met by each Transport Domain involved in the call. 
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► Transport Flow 

I ► QoS Signalling 

( ► Call Signalling 

Figure 3: Generalized TIPIHON Archiitecture withi Service Domain End-to-end QoS Control 

5.2.3.2 Transport Plane control 

In this case, the QoS control of the call between Transport Domains is performed by the local Transport Domain and by 
agreement between Transport Network Operators. QoS SLAs are required between End-Users and ITSPs and between 
Transport Network Operators. The End-Users may first register with their ITSP and receive authorization to make a call 
before estabhshing a media connection with the local Transport Network Operator. 

This approach is a viable option where the Transport Plane comprises a single homogeneous policy space. Addressing, 
Access and QoS mechanisms and policies all have to be uniform for this case to work. 

Figure 4 illustrates the case where end-to-end control of QoS is performed by signalling in the Transport Plane with 
QoS authorization by the access Service Provider. 




>■ Transport Flow 
-^ QoS Signalling 
->- Call Signalling 



Figure 4: Generalized TIPHON Architecture with Transport Plane End-to-end QoS Control 

Hybrid situations are possible where a Service Domain may control several Transport Domains or one Transport 
Domain may control others. Some of these configurations are shown in annex A. 
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5.3 QoS Functional Elements 

The TIPHON QoS mechanisms have elements in both the Transport and in the IP Telephony Application plane. They 
are described in this clause. 

The following Functional Elements are involved in the QoS Control Framework. 



5.3.1 QoS Service IVIanager (QoSIVI) 

A functional entity that mediates requests for end-to-end QoS in accordance with policy determined by the QoSPE. It 
communicates with other QoSMs and with TRMs to determine, establish and control the offered QoS. 

5.3.2 QoS Policy Entity (QoSPE) 

A functional entity that manages IP Telephony QoS policies and provides authorization of permitted and default QoS 
levels. It receives requests from and issues responses to QoSMs to establish the authorized end-to-end QoS levels. 

5.3.3 Transport Resource Manager (TRM) 

A functional entity that applies a set of policies and mechanisms to a set of transport resources to ensure that those 
resources are allocated such that they are sufficient to enable QoS guarantees across the domain of control of the TRM. 

5.3.4 Transport Policy Entity (TPE) 

A functional entity that maintains the policies of a Transport Domain. 



5.3.5 Interconnect Function (ICF) 



A functional entity that interconnects Transport Domains. It provides a policy and/or administrative boundary and may 
police authorized transport flows between two Transport Domains to ensure they are consistent with the QoS policy 
specified by the relevant Transport Resource Manager. 

5.3.6 Transport Function (TF) 

A functional entity representing the collection of transport resources within a Transport Domain which are capable of 
control by a Transport Resource Manager 

5.3.7 Relationship between Functional Entities 

The relationship between these QoS Functional Entities is shown in figure 5. 
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Other 
Service Domains 




-► Transport Flow 



^ QoS Signalling 



Figure 5: TIPHON QoS Functional Entities 



5.4 



QoS Reference Points 



The QoS reference points indicated in figure 5 are derived from the general reference points defined in TS 101 314 [2]. 
They are used for QoS only and are distinguished from their equivalent general reference points by the addition of the 
letter Q. They are extensively explained in clause 8. In this clause a short description of each is given. 

5.4.1 Reference point QC1 

The QoS information flow between a QoSM and a User Equipment QoSM is captured in the QCl reference point. The 
information flow across this reference point communicates QoS related bearer information between an End User and 
the End User's ITSP in the IP Telephony Application Plane. 

5.4.2 Reference point QC2 

Information flowing between two QoSMs in different service domains is captured in QC2. The information flow across 
this reference point communicates QoS related bearer information between domains (ITSPs) in the IP Telephony 
Application Plane. 

5.4.3 Reference point QS4 

Between a QoSM and a QoSPE. The information flow across this reference point communicates QoS policy 
information relating to the establishment of a bearer with specified QoS levels. 

5.4.4 Reference point QT2 

Between a QoSM and its associated TRM(s). The information flow across this reference point communicates QoS 
related transport flow information between a Service Domain and an associated Transport Domain. The information on 
QT2 communicates the QoS related characteristics required of the transport flows that will carry the media flow, the 
properties of the media flow, and addressing information related to the transport flows. 

5.4.5 Reference point QT1 

Between a User Equipment QoSM and an associated Transport Domain. The QoS information flow across this 
reference point communicates the QoS related characteristics required of the local loop transport flows that will carry 
the media flow, the properties of the media flow, and possibly addressing information related to the transport flows. 
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5.4.6 Reference point QI1 



Between a TRM and a TRM in another Transport Domain. The QoS information flow across this reference point 
communicates the QoS related characteristics required of the local loop transport flows that will carry the media flow, 
the properties of the media flow, and possibly addressing information related to the transport flows. 

5.4.7 Reference point QI2 

Between two TRMs in different Transport Domains. The information flow across this reference point communicates the 
QoS related characteristics required of the interconnect transport flows that will carry the media flow, the properties of 
the media flow, and possibly addressing information related to the transport flows. 

5.4.8 Reference point QI3 

Between a TRM and an ICF. The information flow across this reference point controls the Interconnect Function and 
enables it to perform its interworking and policing functions. 

5.4.9 Reference point QI4 

Between a TRM and its associated TPE. The information flow across this reference point is for further study. 

5.4.1 Reference point QI5 

Between a TRM and its associated TF. The information flow across this reference point is for further study. 



6 Characterizing QoS 

6.1 Service, Application and Transport Level QoS Parameters 

Five end-to-end QOS classes applicable to TIPHON systems are defined in TS 101 329 2 [1]. These TIPHON QoS 
classes are expressed in terms of the users perception of QoS and they form a suitable basis for QoS agreements 
between the ITSPs and End-Users. 

Within the IP Telephony application the subjective service level QoS Class is determined by a number of engineering 
parameters which form part of the User Equipment, the network based equipment and the performance of the network 
itself. Examples are the choice of codec, any forward error correction deployed, the packetization algorithm used, the 
codec frame size, the algorithms used for handling packet delay variation at the receiver, the dejittering delay 
introduced at the jitter buffers, error concealment techniques within the decoder and equipment processing delays. At 
the application level, QoS agreements relating to the registration of User Equipment with ITSPs, must be specified in 
terms of these application based parameters. 

In practice most of these parameters will be determined by the User Equipment design, and control of end-to-end QoS 
within the application will be reduced to the control of a number of basic network and equipment related parameters. 
Specifically: 

• maximum end-to-end delay; 

• maximum end-to-end delay variation; 

• maximum Packet loss. 

End-to-end control of these parameters is necessary and sufficient to ensure guaranteed speech quality across a 
particular speech path. Where multiple Transport Domains are involved in a call, the set of parameters must be 
specified and controlled in each domain if quality is to be specified and controlled. 

The QoS achievable at the application and service levels will depend ultimately on the performance of the underlying 
transport networks supporting the IP telephony service. In the Transport Plane therefore the mean end to end delay, 
delay variation and packet loss must be controlled. 
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Figure 6 describes the parameters that are relevant for each level. 



TIPHON Speech QoS Class 




SERVICE 





I 



Codec, Frames per Packet, Frame Size, Jitter Buffer Delay, 

FEC (Redundancy), Overall One-Way Delay, 

Packet Loss 



I 



APPLICATION 



Packet Loss, Mean Delay, Delay Variation 



TRANSPORT 



Figure 6: Service, Application and Transport QoS Parameters 

6.2 Interfacing to the Transport Plane 

Although the QoS requirements arise from the IP Telephony application, the parameters must be controlled in the 
Transport Plane. The QoS requirements are speech quality related and are therefore independent of the mechanisms 
used to control Quality in the transport plane. Thus ATM, RSVP, DiffServ or MPLS or static network engineering 
could all be used to control the required QoS parameters, or even a mixture of these mechanisms where multiple 
Transport Domains are involved. The QoS requirements for a particular media flow must, however, be known to the 
Transport Plane in order that the parameters can be controlled to the required levels. 

For the purposes of interfacing to the transport plane a distinction is made between Transport QoS Parameters, which 
specify the QoS levels to be delivered, and a Traffic Descriptor, which enables the transport network to optimally 
manage the resources required. 

6.2.1 Transport QoS Parameters 

The Transport QoS Parameters (Maximum end-to-end delay. Maximum end-to-end delay variation. Maximum Mean 
Packet Loss) specify the QoS requirements of the transport flow carrying the bearer. 

The format in which these parameters are specified may vary depending on individual circumstances. Different levels of 
instantaneous control are possible and the way in which the parameters are specified will determine this. In general, 
there are three possibilities: 

1) specification of whether QoS is to be controlled on the bearer. Best Effort speech communication implies that 
QoS levels are not specified; 

2) specification that any or all of the three parameters are to be controlled but that the values for the parameters are 
specified elsewhere, e.g. by service level agreements; 

3) specification of the absolute values for the three parameters. 
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These possibilities are provided by the general format of the Transport QoS Parameter Group (see clause 9.2) which 
shall be as follows: 

Sub-Field 1 : Maximum end-to-end delay 

MaxDelayClass (enumeration) Possibility 2 

MaxDelayValue (numeric) Possibility 3 

Sub-Field 2: Maximum end-to-end delay variation 

MaxDelayVariationClass (enumeration) Possibility 2 

MaxDelay Variation Value (numeric) Possibility 3 

Sub-Field 3: Maximum Mean Packet Loss 

MaxMeanPacketLossClass (enumeration) Possibility 2 

MaxMeanPacketLoss Value (numeric) Possibility 3 

where the above parameters are defined as follows: 

MaxDelayClass: 

This parameter shall specify a number representing an entry in a list of possible maximum delay values and based on a 
priori agreement between business entities. The values of maximum delay to be included in this list are for further 
study. 

MaxDelayValue: 

This parameter shall be used to specify the numerical value of the maximum delay. 

MaxDelayVariationClass: 

This parameter shall specify a number representing an entry in a list of possible maximum delay variation values and 
based on a priori agreement between business entities. The values of maximum delay variation to be included in this list 
are for further study. 

MaxDelay Variation Value : 

This parameter shall be used to specify the numerical value of the maximum delay variation. 

MaxMeanPacketLossClass: 

This parameter shall specify a number representing an entry in a list of possible maximum mean packet loss values and 
based on a priori agreement between business entities. The values of maximum mean packet loss to be included in this 
list are for further study. 

MaxMeanPacketLoss Value: 

This parameter shall be used to specify the numerical value of the maximum mean packet loss. 

For Possibility 1, where no QoS control is required, the transport QoS Parameter Group shall be omitted from 
information exchanges. 

NOTE 1 : The way in which the above variables are characterized is for further study. 

NOTE 2: The use of a parameter to indicate the maximum permitted levels of packet loss in a burst of specified 
duration is for further study. 
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6.2.2 Traffic Descriptor 



The traffic statistics of each bearer may be specified and signalled to the transport plane for resource management and 
admission control purposes. The QoS levels for a media flow will be guaranteed only in the case that the flow remains 
conformant to its Traffic Descriptor. The format of the Traffic Descriptor shall be as follows: 

PeakBitRate (numeric) 

PacketSize (numeric) 

where these are defined as follows: 

PeakBitRate 

This is defined as the maximum rate of the media flow at which the transport domain is required to sustain QoS 
guarantees. (The overhead from RTP or equivalent framing shall be included in this figure). 

For constant bit rate (CBR) media flows, the Peak Bit Rate is sufficient to enable optimum resource utilization in the 
transport plane. 

PacketSize 

This is defined as the maximum size of the media packets including the RTP overhead. 

The characterization of variable bit rate (VBR) media flows may require further parameters such as the average bit rate 
of the flow, or a parameter indicating the burstiness of the media flow. For transport resource optimization this 
information is likely to be derived from measurement within the Transport Plane rather than from the End-User or the 
IP Telephony Application Plane. The extension of the Traffic Descriptor to characterize VBR media flows is for further 
study. 



7 Allocating the QoS Budget across Service and 

Transport Domains 

In the generalized model shown in figure 3 it is assumed that the TIPHON system is divided into a number of separate 
Transport Domains and Service Domains and that a call through the TIPHON system will in general pass through a 
number of such domains. 

End-to-end QoS requirements can be regarded as end-to-end quality budgets related to the media flows. To achieve the 
required end-to-end QoS these quality budgets must be allocated between the domains, including the user equipment, as 
illustrated in figure 7. The Transport QoS Parameters specify the QoS budgets for each Transport Domain. It is assumed 
that the performance of each domain is statistically independent from any other, in which case the overall accumulation 
of QoS parameter values may be calculated as follows: 

• delay is additive, i.e. D^t = Dj H- D2 + D„; 

• packet loss accumulates on a probabilistic basis, i.e. P^^^ = 1 - [(1 - Pj ) * (1 - Pj ) * (1 - P^^ )J ; 



/ 2 2 2 

• delay variation accumulates on an RMS basis, i.e. DVji^j = -wDVj -I- DV2 + DV^^ 

where: 

D„ is the mean one-way delay of domain n; 

Pn is the packet loss probability of domain n; 

D Vn is the standard deviation of the delay variation of domain n. 
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End-to-End Budgets 



User Equipment Budget 
M ► 



User Equipment Budget 

Transport Domain Budgets "^ ► 

->- -^ ^ -^ ► 




Figure 7: Allocation of TIPHON QoS Budgets 

The present document describes three ways in which to apportion the QoS budget between domains: 

• dynamic signalHng of Transport QoS Parameters end-to-end between ITSPs on a per call [or event] basis; 

• static Service Level Agreements (SLAs) between ITSPs which define the Transport QoS parameters for calls 
passing through their domain of control. This approach will also require policies in the SLAs specifying the 
maximum number of domains end-to-end that will be involved in a call; 

• aggregation of Transport Domain resource and caching of information on its availability in which dynamic but 
infrequent signalling of Transport QoS parameters enables a knowledge of the Transport QoS Parameters that 
may be supported at any point of time to be ascertained. 

NOTE: The allocation of budgets between User Equipment and Network must be established before the call 

either by SLA at time of registration, or by dynamic signalling at call set-up, or by a combination of both. 

7.1 Dynamic signalling of Transport QoS Parameters 

Dynamic signalling of Transport QoS Parameters allows an ITSP to signal the QoS requirements on a per call basis. 

Call-Control signalling takes place in the Application Plane between ITSPs, and between End-Users & ITSPs. 
Similarly, QoS signalling takes place on the basis of SLAs between End-Users & ITSPs and between ITSPs, and 
follows Call Routing. 

Between each ITSP involved in the call and its associated Transport Domain(s), Transport QoS Parameter signalling 
takes place again on the basis of SLAs to ensure that the required Transport QoS Parameters are met by each Transport 
Domain involved in the call. Some of these parameters may be in the SLA and some signalled dynamically, clause 9 
describes the procedures used for dynamic QoS controlled call establishment. 

7.2 Specification of Transport QoS Parameters in Service Level 
Agreements 

SLAs are part of the peering agreement between ITSPs. These may specify the Transport QoS Parameters for calls 
passing through their Transport Domain(s) of control, thereby obviating the need to signal these parameters on a per call 
basis. Where Transport QoS Parameters are specified in this way, end-to-end signalling may be restricted to resource 
availability to support Service Class (TIPHON QoS Class or possibly a Transport QoS Parametric class). 



7.3 Aggregation 



With aggregated transport resource reservation or bulk reservation the IP Telephony Application Plane reserves an 
amount of resources for media transport that is sufficient to support a number of media flows. This allows the 
application plane to more efficiently use allocated resources by using statistical multiplexing of variable bit-rate media 
streams. Using aggregated transport reservation also saves on signalling as the Transport Plane may not need to be 
contacted for each call. 
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Resource aggregation may be performed in the Transport Plane under the control of either Transport Network Operators 
or ITSPs. Aggregation involves a quantity of transport resource with guaranteed QoS characteristics being allocated 
prior to the set up of an individual media flow. Individual media flows will then consume a portion of this. In both cases 
requests to set up a QoS controlled connection may therefore be made without exchanging QoS parameters on a 
per-flow basis. 

7.3.1 Aggregation under control of the TRM 

In the case where aggregation is controlled by the Transport Network Operators the role of the TRM will then be to 
monitor the allocation of this resource. Mechanisms such as MPLS and IntServ may be used for this purpose. The IP 
telephony application is unaware of the aggregation taking place in the transport plane, therefore this case is outside the 
scope of the present document. 

7.3.2 Aggregation under control of the QoSM 

When control of the aggregated resource is by a Service Provider a QoSM may reserve a quantity of transport resource 
with guaranteed QoS characteristics prior to the set up of an individual media flow. This would be by agreement with 
the Transport Network Operator. The QoSM then maintains the availability of QoS reserved resource calculating the 
actual utilization of the aggregate resource. 

Resource aggregation requires aggregate bearer bandwidth management and connection admission control 
functionality. 

An aggregate resource has one source and one destination IP address in each Transport Domain. Multiple bearers are 
multiplexed, for example, by means of their port number using the same IP header belonging to an aggregate. When 
reserving aggregate resource the IP Telephony Application Plane shall send to the Transport Plane the aggregate IP 
address with for example, a range of port numbers, (to be multiplexed over the aggregate resource). It is desirable that 
all these ports shall be opened by the ICF, thus avoiding per-bearer communication between the IP Telephony 
Application and Transport Planes. 

The following methods are identified for aggregate resource creation: 

• Provisioning on a semi-permanent basis (pre-assigned). 

• Dynamic aggregate resource establishment/clear down. 

NOTE: A dynamic aggregate may also be implemented with optional bandwidth negotiation. 

Connection admission control to the aggregate resource shall be performed on a per bearer basis. The resource usage 
information may be used for connection admission control. 

Aggregate resource usage can be calculated by different methods, e.g. 

• Traffic engineering methods taking into account Traffic Descriptors; 

• Resource usage measurements. 

Resource reservation renegotiation may take place at any time. For example when the resource usage of the aggregate 
flow exceeds a predetermined percentage of the reserved resource the allocation may be renegotiated or a new 
aggregate flow created. Similarly in low traffic conditions it may be desirable to renegotiate a lower aggregate 
reservation. 



8 QoS Primitives 



Figure 8 shows the general model for the QoS information flows introduced in clause 5. These include QoS information 
flows between IP Telephony Application Plane domains, between Transport Plane domains and information flows 
between an IP Telephony Application Plane domain and a corresponding Transport Plane domain. 

For end-to-end QoS control the information flows shall be exchanged between previous and subsequent IP Telephony 
Application Plane domains and/or Transport Domains. At each reference point information shall be exchanged via QoS 
Primitives. The figure shows the QoS Primitives defined at each of the reference points. 
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Application Plane 
Transport Plane 



Previous 
domain 



Subsequent 
domain 



Figure 8: Model of QoS information flows. 

NOTE: The model shows uni-directional end-to-end QoS establishment. The same model shall also apply in the 
bi-directional end-to-end QoS establishment case. 



8.1 



QoS Primitives 



NOTE: Primitives required for renegotiation of properties are for further study. 

8.1.1 QC1and2 

The information flow across this reference point shall communicate QoS related bearer information between domains 
(ITSPs) in the IP Telephony Application Plane (QC2) or between User Equipment and a Service Domain (QCl). 

The following primitives are defined: 

QoSM request (QCl/2.QoSMreq) requests the establishment of a bearer conforming to a particular TIPHON Class of 
Service or with defined QoS characteristics. 

QoSM confirm (QCl/2.QoSMconf) acknowledges the creation of a bearer conforming to a requested TIPHON QoS 
Class or with specified QoS characteristics. 

QoSM reject (QCl/2.QoSMrej) rejects the creation of a bearer conforming to a requested TIPHON QoS Class or with 
specified QoS characteristics. 

QoSM release request (QCl/2.QoSMrelreq) requests the release of a bearer. 

QoSM release confirm (QCl/2.QoSMrelconf) confirms the release of a bearer. 
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8.1.2 QS4 

The information flow across this reference point shall communicate QoS policy information relating to the 
establishment of a bearer with specified QoS levels. 

The following primitives are defined: 

QoSPE request (QS4.QoSPEreq) requests authorization for the establishment of a bearer with defined QoS 
characteristics. 

QoSPE confirm (QS4.QoSPEconf) confirms authorization for the establishment of a bearer with defined QoS 
characteristics. 

QoSPE reject (QS4.QoSPErej) rejects authorization for the establishment of a bearer with defined QoS 
characteristics. 

8.1.3 QT2 

The information flow across this reference point shall communicate QoS related transport flow information between a 
Service Domain and an associated Transport Domain. The information on QT2 shall communicate the QoS related 
characteristics required of the transport flows that will carry the media flow, the properties of the media flow, and 
addressing information related to the transport flows. 

The following primitives are defined: 

TRM QoS request (QT2.TRMQreq) requests the establishment of a transport flow with defined QoS characteristics 
across a Transport Domain or the reservation of Transport Domain resource. 

TRM QoS confirm (QT2.TRMQconf) acknowledges the creation of a requested transport flow or the reservation of 
Transport Domain resource. 

TRM QoS reject (QT2.TRMQrej) rejects the creation of a requested transport flow or the reservation of Transport 
Domain resource. 

TRM QoS release request (QT2. TRM QoS relreq) requests the release of a transport flow. 

TRM QoS release confirm (QT2. TRM QoS relconf) confirms the release of a transport flow. 

TRM QoS performance notification (QT2. TRM QoS perfnotif) notifies the Service Domain of the performance of 
the Transport Domain in meeting the requested QoS levels. This may be a periodic event or an urgent alarm. 

NOTE: This primitive is a management primitive and its use is for further study. 

8.1.4 QT1 

The information flow across this reference point shall communicate QoS related transport flow information between 
User Equipment QoSM and an associated Transport Domain. The information on QTl shall communicate the QoS 
related characteristics required of the transport flows that will carry the media flow, the properties of the media flow, 
and addressing information related to the transport flows. 

The following primitives are defined: 

QoS request (QTl.TRMQreq) requests the establishment of a transport flow with defined QoS characteristics across a 
Transport Domain or the reservation of Transport Domain resource. 

QoS confirm (QTl.TRMQconf) acknowledges the creation of a requested transport flow or the reservation of 
Transport Domain resource. 

QoS reject (QTl.TRMQrej) rejects the creation of a requested transport flow or the reservation of Transport Domain 
resource. 

QoS release request (QTl.TRMQrelreq) requests the release of a transport flow. 

QoS release confirm (QTl.TRMQrelconf) confirms the release of a transport flow. 
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8.1.5 QI1 



The information flow across this reference point shall communicate QoS related transport flow information between a 
User Equipment TRM and a TRM in another Transport Domain. The information on Qll shall communicate the QoS 
related characteristics required of the transport flows that will carry the media flow, the properties of the media flow, 
and addressing information related to the transport flows. 

The following primitives are defined: 

QoS request (QIl.TRMQreq) requests the establishment of a transport flow with defined QoS characteristics across a 
Transport Domain or the reservation of Transport Domain resource. 

QoS confirm (QIl.TRMQconf) acknowledges the creation of a requested transport flow or the reservation of 
Transport Domain resource. 

QoS reject (QIl.TRMQrej) rejects the creation of a requested transport flow or the reservation of Transport Domain 
resource. 

QoS release request (QIl.TRMQrelreq) requests the release of a transport flow. 

QoS release confirm (QIl.TRMQrelconf) confirms the release of a transport flow. 

8.1.6 QI2 

The information flow across this reference point shall communicate QoS related transport flow information between 
two associated Transport Domains. The information on Q12 shall communicate the QoS related characteristics required 
of the transport flows that will carry the media flow, the properties of the media flow, and addressing information 
related to the transport flows. 

The following primitives are defined: 

QoS request (QI2.TRMQreq) requests the establishment of a transport flow with defined QoS characteristics across a 
Transport Domain or the reservation of Transport Domain resource. 

QoS confirm (QI2.TRMQconf) acknowledges the creation of a requested transport flow or the reservation of 
Transport Domain resource. 

QoS reject (QI2.TRMQrej) rejects the creation of a requested transport flow or the reservation of transport domain 
resource. 

QoS release request (QI2.TRMQrelreq) requests the release of a transport flow. 

QoS release confirm (QI2. TRMQrelconf) confirms the release of a transport flow. 

8.1.7 QI3 

The information flow across this reference point shall communicate QoS related transport flow information between a 
TRM and an ICF within a Transport Domain. The information on Q13 may communicate the QoS related characteristics 
required of the transport flows that will carry the media flow, the properties of the media flow or QoS mechanism 
related information and addressing information related to the transport flows. 

The following primitives are defined: 

QoS request (QI3.ICFQreq) requests the establishment of a transport flow with defined QoS characteristics and 
mechanisms into or out of a Transport Domain. 

QoS confirm (QI3.ICFQconf) acknowledges the creation of a requested transport flow. 

QoS reject (QI3.ICFQrej) rejects the creation of a requested transport flow. 

QoS release request (QI3. ICFQ relreq) requests the release of a transport flow. 

QoS release confirm (QI3. ICFQrelconf) confirms the release of a transport flow. 
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8.1.8 QI4 



The information flow across this reference point shall contain requests and authorizations for the established of QoS 
controlled transport flows through a Transport Domain and policy related information specific to the QoS mechanisms 
involved. 

NOTE: The information flows on this interface are for further study. 

The following primitives are defined: 

QoS Policy request (QI4.PQreq) requests authorization for the establishment of a transport flow with defined QoS 
characteristics and may request a QoS mechanism and ICF address. 

QoS Policy confirm (QI4.PQconf) provides authorization for the establishment of the transport flow and defines QoS 
mechanism and ICF address. 

QoS Policy reject (QI4.PQrej) rejects the creation of a requested transport flow. 

8.1.9 QI5 

The information flow across this reference point shall communicate QoS related transport flow information between a 
TRM and Transport Functionality within a Transport Domain. The information on QI5 may communicate the QoS 
related characteristics required of the transport flows and the QoS mechanism related information that will be used to 
achieve this. The information flows on this interface are for further study. 

The following primitives are defined: 

QoS request (QIS.TFQreq) requests the establishment of a transport flow with defined QoS characteristics and 
mechanisms within a Transport Domain. 

QoS confirm (QIS.TFQconf) acknowledges the creation of a requested transport flow. 

QoS reject (QIS.TFQrej) rejects the creation of a requested transport flow. 

QoS release request (QI5.TFQ relreq) requests the release of a transport flow. 

QoS release confirm (QIS.TFQrelconf) confirms the release of a transport flow. 
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8.2 QoS Parameters Groups 
8.2.1 QoS parameter groups 

The QoS primitives defined in clause 8.1 shall contain a number of parameters from the following defined parameter 
groups. 



Parameter Group 


Description 


Parameters 


Description 


QoS Service Class 


Describes the end-to- 
end TIPHON class of 
a bearer. 


Best, High, IVIedium or 
Best Effort. 


Parameters specifying the TIPHON 
QoS Class as defined in ETSI 
TS 101 329-2 [1]. 


Codec Type and 
Packetization 


Describes the Codec 
type used on a bearer 
and the way the 
media is packetized. 


Codec Type (Optionally 
a list of possible codecs). 


Codec Identifier including any 
relevant codec parameters, e.g. 
version number, sampling rate, etc. 


Frames per packet 
(Optionally a list when 
codec lists are specified). 


Number of frames per packet. 


Transport QoS 
Parameters 


Specifies the QoS 
characteristics 
required of the 
transport flow 
carrying the media 
flow. 


IVIaximum Delay 


The maximum delay permitted over 
either a segment of the transport 
flow or the remaining part of the 
transport flow. 


Maximum Packet Delay 
Variation 


The maximum packet delay 
variation permitted over either a 
segment of the transport flow or the 
remaining part of the transport flow. 


Maximum Mean Packet 
Loss 


The maximum mean packet loss 
permitted over either a segment of 
the transport flow or the remaining 
part of the transport flow. [Note: 
This measure assumes randomly 
distributed packet loss]. 


Traffic Descriptor 


Characterizes the 
resource 

requirements of an 
application data flow 
(excludes transport 
flow resource 
requirements). 


Peak Bit 


Maximum bit rate (bit/s) of the 
media flow. 


Maximum Packet Size 


Maximum size of the media 
packets. 


Caller and Callee IDs 


Specifies the identity 
of the calling and 
called parties. As 
defined in 
TS101 314 [2]. 


Calling ID 


The identity of the calling party. 


Callee ID 


The identity of the called party. 


Transport Addresses 


Specifies addressing 
information defining 
the transport flow 
carrying the bearer. 


Originator Transport 
Address 


The originator transport address 
(typically IP address and port/set of 
ports) within a transport domain. 


Destination Transport 
Address 


The destination transport address 
(typically IP address and port/set of 
ports) within a transport domain. 


Application Data 
Transport Protocol 


Specifies the 
application data 
transport protocol of 
the bearer. 


Protocol ID 


Identifier of the application data 
transport protocol used by the 
bearer. Typically RTP. 


Packet Transport 
Protocol 


Specifies the packet 
transport protocol. 


Protocol ID 


Identifier of the packet transport 
protocol used in the transport flow. 
Typically UDP. 


QoS Policy 


Describes the policy 
determining the users 
entitlement to QoS 
Service Class. 


TBD 


TBD 


QoS Mechanism 


Describes the 
mechanism used in 
the Transport Plane. 


Type 


None, RSVP/INTSERV, 
DIFFSERVorMPLS. 


Mechanism specific 
parameters 


TBD 


Authorization Token 


TBD 
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8.2.2 QC1 

The following list defines the parameters used in the QCl primitives. 



Primitive 


Parameter 


Status 


QCI.QoSIMreq 


OoS Service Class 

Codec Type and Packetization 

Transport QoS Parameters 

Traffic Descriptor 

Transport Addresses 

Caller and Called IDs 

Application Data Transport Protocol 

Packet Transport Protocol 


Mandatory 

Mandatory 

Optional 

Optional 

Mandatory 

Mandatory 

Optional [Default RTP] 

Optional [Default UDP] 


QCl .QoSIMconf 


OoS Service Class 

Codec Type and Packetization 

Transport QoS Parameters 

Transport Addresses 

Application Data Transport Protocol 

Packet Transport Protocol 

OoS Mechanism 


Mandatory 

Mandatory 

Optional 

Mandatory 

Optional [Default RTP] 

Optional [Default UDP] 

Optional 


QCI.QoSIVIrej 


Reason [TBD] 


Mandatory 



8.2.3 QC2 

The following list defines the parameters used in the QC2 primitives. 



Primitive 


Parameter 


Status 


QC2.QoSI\/lreq 


OoS Service Class 

Codec Type and Packetization 

Transport QoS Parameters 

Traffic Descriptor 

Transport Addresses 

Application Data Transport Protocol 

Packet Transport Protocol 

QoS Mechanism 


Optional 

Mandatory 

Mandatory 

Optional 

Mandatory 

Optional [Default RTP] 

Optional [Default UDP] 

Optional 


QC2.QoSIVIconf 


QoS Service Class 

Codec Type and Packetization 

Transport QoS Parameters 

Transport Addresses 

Application Data Transport Protocol 

Packet Transport Protocol 


Optional 

Mandatory 

Mandatory 

Mandatory 

Optional [Default RTP] 

Optional [Default UDP] 


QC2.QoSIVIrej 


Reason [TBD] 


Mandatory 



8.2.4 QS4 

The following list defines the parameters used in the QS4 primitives. 



Primitive 


Parameter 


Status 


QS4.QoSPEreq 


QoS Service Class 
Caller Identity 
Called Identity 


Mandatory 
Mandatory 
Mandatory 


QS4.QoSPEconf 


QoS Service Class 
Caller Identity 
Called Identity 


Mandatory 
Mandatory 
Mandatory 


QS4. QoSPErej 


Reason [TBD] 


Mandatory 
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8.2.5 QT2 

The following list defines the parameters used in the QT2 primitives. 



Primitive 


Parameter 


Status 


QT2.TRIVIQreq 


Transport QoS Parameters 
Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 


Mandatory 
Mandatory 
Mandatory 
Optional [Default UDP] 


QT2.TRMQconf 


Transport QoS Parameters 
Transport Addresses 
Packet Transport Protocol 
OoS Mechanism 


Mandatory 

Mandatory 

Optional [Default UDP] 

Optional 


QT2.TRIVIQrej 


Reason [TBD] 


Mandatory 



8.2.6 QT1 

The following list defines the parameters used in the QTl primitives. 



Primitive 


Parameter 


Explanation 


QTl.TRIMQreq 


Transport QoS Parameters 
Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 
QoS Mechanism 


Mandatory 

Optional 

Mandatory 

Optional [Default UDP] 

Optional 


QTl.TRMQconf 


Transport QoS Parameters 
Transport Addresses 
Packet Transport Protocol 


Mandatory 
Mandatory 
Optional [Default UDP] 


QTl.TRIMQrej 


Reason [TBD] 


Mandatory 



8.2.7 QI1 

The following list defines the parameters used in the QIl primitives. 



Primitive 


Parameter 


Explanation 


QTl.TRIVIQreq 


Transport QoS Parameters 
Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 
QoS Mechanism 


Mandatory 

Optional 

Mandatory 

Optional [Default UDP] 

Optional 


QTl.TRMQconf 


Transport QoS Parameters 
Transport Addresses 
Packet Transport Protocol 


Mandatory 
Mandatory 
Optional [Default UDP] 


QTl.TRIMQrej 


Reason [TBD] 


Mandatory 



8.2.8 QI2 

The following list defines the parameters used in the QI2 primitives. 



Primitive 


Parameter 


Explanation 


QI2.TRMQreq 


Transport QoS Parameters 
Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 


Mandatory 

Optional 

Mandatory 

Optional [default UDP] 


QI2.TRMQconf 


Transport QoS Parameters 
Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 


Mandatory 

Optional 

Mandatory 

Optional [default UDP] 


QI2.TRMQrej 


Reason [TBD] 


Mandatory 
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8.2.9 QI3 

The following list defines the parameters used in the QI3 primitives. 



Primitive 


Parameter 


Explanation 


QIS.ICFQreq 


Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 
OoS Mechanism 


Optional 

Mandatory 

Optional [default UDP] 

Mandatory 


QIS.ICFQconf 


Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 
OoS Mechanism 


Optional 

Optional 

Optional [default UDP] 

Optional 


QIS.ICFQrej 


Reason [TBD] 


Mandatory 



8.2.10 QI4 

The following list defines the parameters used in the QI4 primitives. 



Primitive 


Parameter 


Explanation 


QI4.PQreq 


Transport QoS Parameters 
Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 
OoS Mechanism 


Optional 

Optional 

Mandatory 

Optional [default UDP] 

Optional 


QI4.PQconf 


Transport QoS Parameters 
Traffic Descriptor 
Transport Addresses 
OoS IVIechanism 


Optional 
Optional 
Optional 
Optional 


QI4.PQrej 


Reason [TBD] 


Mandatory 



8.2.11 QI5 

Details of the parameters and primitives on this reference point are for further study. 



9 QoS Procedures (Informational) 

The QoS Primitives defined in clause 8 can be used in a number of QoS related procedures. 

9.1 Third Party Establishment of QoS Controlled Bearer 

In this situation a third party, typically a Service Provider, establishes a QoS controlled bearer on behalf of a calling 
party by signalling the required QoS characteristics to the Transport Plane. See clause 5.2.3.1 and figure 3. 

The functional elements involved are shown in figure 9. The QoSM in the terminal requests service of the QoSM in 
Service Domain 1 . This QoSM establishes a QoS controlled bearer by communicating with the TRM in Transport 
Domain 1 and QoSM in Service Domain 2. 
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ICF1 



QI3 ^|CF2 
Transport Domain 1 



Figure 9: Functional elements involved in Third Party Bearer Establishment 

The information flows are shown in figure 10. 
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Figure 10: Information Flows for Third Party QoS Bearer Establishment 
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The primitives carry the following parameters. Other optional parameters listed in clause 8 are not required for this 
procedure. 



Primitive 


Parameter 


QC1 .QoSIVIreq 


QoS Service Class 

Codec Type and Packetization 

Application Data Transport protocols 

Packet Transport Protocol 

Caller and Called ID 

Originating Transport Address 


QS4.QoSPEreq 


OoS Service Class 
Caller and Callee IDs 


QS4.QoSPEconf 


OoS Service Class 
Caller and Callee IDs 


QT2.TRIVIQreq 


Transport OoS Parameters 
Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 


QI4.PQreq 


Transport QoS parameters 
Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 


QI4.PQconf 


Transport OoS Parameters 
Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 
OoS Mechanism 


QI3.ICFQreq 


Traffic Descriptor 

Transport Addresses 

Packet Transport Protocol 

OoS Mechanism (including mechanism parameters) 


QI3.ICFQconf 


Traffic Descriptor 

Transport Addresses 

Packet Transport Protocol 

OoS Mechanism (including mechanism parameters) 


QT2.TRIVlQconf 


Transport OoS Parameters 
Transport Addresses 
Packet Transport Protocol 


QC2.QoSI\/lreq 


OoS Service Class 

Codec Type and Packetization 

Transport OoS Parameters 

Transport Addresses 

Application Data Transport Protocols 

Packet Transport Protocol 


QC2.QoSMconf 


OoS Service Class 

Codec Type and Packetization 

Transport OoS Parameters 

Transport Addresses 

Application Data Transport Protocols 

Packet Transport Protocol 


QC1 .QoSMconf 


OoS Service Class 

Codec Type and Packetization 

Transport Addresses 

Application Data Transport Protocols 

Packet Transport Protocol 



£75/ 



30 



ETSI TS 101 329-3 V2.1.1 (2001-09) 



9.2 First Party Establishment of QoS Controlled Bearer 

In this situation the calling party establishes a QoS controlled bearer directly by signalling the necessary QoS 
characteristics to the Transport Plane. See clause 5.2.3.2 and figure 4. 

The functional elements involved are shown in figure 1 1 . The QoSM in the initiating terminal first establishes 
compatible codecs via end-to-end Application Plane signalling. At the same time the QoS parameters of the responding 
terminal must be established. QoS transport budgets will then be determined by the QoSM in Service Domain 1 and 
communicated to the QoSM in the initiating terminal. The QoS controlled bearer is then estabUshed directly by 
signalling between the initiating terminal and the TRM in Transport Domain 1 . This TRM communicates in the usual 
way with the TPE and ICFs in Transport Domain 1 and subsequently with the TRM in Transport Domain 2. 

NOTE: In this scenario the Service Provider can only offer guarantees about the quality levels achievable from 
the Transport Plane via fixed parameters in service level agreements with Transport Operators. Other 
factors such as Network Address Translation and Firewalls may also present difficulties. 




Figure 11: Functional elements involved in First Party Bearer Establishment 
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The information flows are shown in figure 12. 

UEQoSM QoSM(1) QoSPE(l) TRWI (1) 

(1)QC1.QoSMReq 

(2) QS4.QoSPEReq 

(3) QS4.QoSPEConf 



ICF1,2 TPE(1) QoSM (2) TRM (2) 



(6) QC1 .QoSMConf 



(14)QT1.TRMQConf 



(5) QC2.QoSMConf 



(7)QT1.TRMReq 



(8) QI4.PQReq 

(9) QM.PQConf 
(10)QI3.ICFQReq 
(11)QI3.ICFQConf 



(4) QC2.CtoSMReq 




Figure 12: Information Flows for First Party QoS Bearer Establishment 



£75/ 



32 



ETSI TS 101 329-3 V2.1.1 (2001-09) 



The flows contain the following parameters: 



Primitive 


Parameter 


QCI.QoSIVlreq 


QoS Service Class 

Codec Type and Packetization 

Application Data Transport Protocols 

Packet Transport Protocol 

Caller and Called ID 

Originating Transport Address 


QS4.QoSPEreq 


QoS Service Class 
Caller and Callee IDs 


QS4.QoSPEconf 


QoS Service Class 
Caller and Callee IDs 


QC2.QoSMreq 


QoS Service Class 

Codec Type and Packetization 

Transport QoS Parameters 

Transport Addresses 

Application Data Transport Protocols 

Packet Transport Protocol 


QC2.QoSI\/lconf 


QoS Service Class 

Codec Type and Packetization 

Transport QoS Parameters 

Transport Addresses 

Application Data Transport Protocols 

Packet Transport Protocol 


QCI.QoSMconf 


QoS Service Class 

Codec Type and Packetization 

Transport Addresses 

Application Data Transport Protocols 

Packet Transport Protocol 


QTl.TRMreq 


Transport QoS Parameters 
Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 


QI4.PQreq 


Transport QoS Parameters 
Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 


QI4.PQconf 


Transport QoS Parameters 
Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 
QoS Mechanism 


QI3.ICFQreq 


Transport QoS Parameters 

Traffic Descriptor 

Transport Addresses 

Packet Transport Protocol 

QoS IVIechanism 

NQTE: IVIechanism dependent signalling will take place here. 


QI3.ICFQconf 


Transport QoS Parameters 
Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 


QTl.TRMconf 


Transport QoS Parameters 
Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 
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9.3 Hybrid Third Party/First Party Establishment of QoS 
Controlled Bearer via authorization tokens 

In this situation the calling party establishes a QoS controlled bearer directly by signalling the necessary QoS 
characteristics to the Transport Plane but after receiving authorization from a Service Provider. 

This mechanism overcomes some of the difficulties associated with First Party bearer establishment. 

The functional elements involved are shown in the figure 13. The QoSM in the terminal communicated directly with the 
TRM in Transport Domain 1 but also with the QoSM in Service Domain 1 . The TRM in transport Domain 1 
communicates in the usual way with the TPE and ICFs in Transport Domain 1 . Remaining legs of the bearer may either 
be established via the Application Plane or by signalUng within the Transport Plane between TRMs. 




Figure 13: Functional elements involved in Hybrid Third Party/First Party Bearer Establishment 
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The information flows are shown in figure 14. 

UEQoSM QoSM(1) QoSPE(l) TRWI (1) 

(1)QC1.QoSMReq 

(2) QS4.QoSPEReq 

(3) QS4.QoSPEConf 



ICF1,2 TPE(1) QoSM (2) TRM (2) 




(5) QI4.PQReq 

(6) QI4.PQConf 

(7) QIS.ICFQReq 

(8) QI3.ICFQConf 




Figure 14: Information Flows for Hybrid Third Party/First Party Bearer Establishment 
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The flows contain the following parameters: 



Primitive 


Parameter 


QCI.QoSWIreq 


QoS Service Class 

Codec Type and Packetization 

Application Data Transport Protocols 

Packet Transport Protocol 

Caller and Called ID 

Qriginating Transport Address 


QS4.QoSPEreq 


QoS Service Class 
Caller and Callee IDs 


QS4.QoSPEconf 


QoS Service Class 
Caller and Callee IDs 


QT2.TRMQreq 


Transport QoS Parameters 
Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 


QI4.PQreq 


Transport QoS Parameters 
Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 


QI4.PQconf 


Transport QoS Parameters 
Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 
QoS IVIechanism 
QoS Token 


QI3.ICFQreq 


Traffic Descriptor 

Transport Addresses 

Packet Transport Protocol 

QoS Mechanism (including mechanism parameters) 

QoS Token 


QI3.ICFQconf 


Traffic Descriptor 

Transport Addresses 

Packet Transport Protocol 

QoS Mechanism (including mechanism parameters) 


QT2.TRMQconf 


Transport QoS Parameters 
Transport Addresses 
Packet Transport Protocol 
QoS Token 


QC2.QoSI\/lreq 


QoS Service Class 

Codec Type and Packetization 

Transport QoS Parameters 

Transport Addresses 

Application Data Transport Protocols 

Packet Transport Protocol 


QC2.QoSMconf 


QoS Service Class 

Codec Type and Packetization 

Transport QoS Parameters 

Transport Addresses 

Application Data Transport Protocols 

Packet Transport Protocol 


QC1 .QoSMconf 


QoS Service Class 

Codec Type and Packetization 

Transport Addresses 

Application Data Transport Protocols 

Packet Transport Protocol 

QoS Token 


QTl.TRMreq 


Transport Addresses 
QoS Token 


QI2.TRMreq 


Transport QoS Parameters 
Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 


QI2.TRIVIconf 


Transport QoS Parameters 
Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 
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Primitive 


Parameter 


QTl.TRMconf 


Transport QoS Parameters 
Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 



9.4 Terminal Registration 



For further study. 
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Annex A (informative): 

Examples of End-to-End QoS Control 

This annex describes a number of different ways in which the general QoS architecture can be used to estabhsh a QoS 
controlled bearer. 



A.1 One service domain/One transport domain 




QoS Signalling 
Call/Bearer Signalling 



Transport Signalling 
lUledia Path 



Figure 15: One Service Domain/One Transport Domain 

In this scenario one service domain and one transport domain are shown. 
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A.2 One service domains/multiple transport domains 
Case I 




QoS Signalling 
Call/Bearer Signalling 



->- Transport Signalling 
-► Media Path 



Figure 16: One Service Domain/IVIultiple Transport Domains - Case I 

In this scenario multiple transport domains are under the control of one service domain. 

Each transport domain has a direct relationship with the controlling service domain. The service domain will have to 
arrange the resources and make sure the transport channel is connected end-to-end. 

Such a deployment requires the service domain to be aware of the location of the ICFs of each of the transport domains 
in order to connect them. 
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A.3 One service domain/multiple transport domains 
Case II 




QoS Signalling 
Call/Bearer Signalling 



->- Transport Signalling 
-► Media Path 



Figure 17: One Service Domain/IVIultiple Transport Domains - Case II 

In this scenario multiple transport domains are shown for one service domain and there is only one interface between 
the application and transport planes. 

The group of transport domains looks to the service domain as one domain. One transport domain may be the master 
contractor communicating with the other TRMs (either in parallel or each TRM communicating with the next) to set up 
the aggregate channel end-to-end. 

The communication between the TRMs will look like the signalling across reference point QT2. 

Such a deployment requires that all the transport domains for each end-to-end bearer must maintain a uniform set of 
policies regarding addressing and QoS mechanisms. Potentially, there will also be issues of security to be addressed in 
passing the QTl signalling across the boundary of the two transport domains. 
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A.4 Multiple service domains/multiple transport domains 




QoS Signalling 
Call/Bearer Signalling 



-► Transport Signalling 
-► Media Path 



Figure 18: Multiple Service Domains/Multiple Transport Domains - Case I 

In this scenario the communication between multiple service domains is handled by multiple transport domains. 

The bearer is established by transport domain 1 as master contract to service domain 1 so that the subsequent transport 
domains can be considered as extensions of the transport domain belonging to Service Domain 1 . 

A.5 Multiple service domains/multiple transport domains 




QoS Signalling 
Call/Bearer Signalling 



->^ Transport Signalling 
-► Media Path 



Figure 19: Multiple Service Domains/Multiple Transport Domains - Case II 

Again in this scenario the communication between multiple service domains is handled by multiple transport domains. 
However several transport domains may be involved in the control of the bearer. 
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Each transport domain has a direct relationship with its controlling service domain. The service domain will have to 
arrange the resources and make sure the bearer is connected end-to-end. 

As with Scenario in clause A. 1 such a deployment requires the service domains to be aware of the location of the ICFs 
of each of the transport domains in order to connect them. 



A.6 Roaming 




■^ ► Transport Flow 

A ► QoS Signalling 

•4 ► Call Signalling 



TRM 



Transport Resource IVIanager 



Figure 20: Multiple Service Domains/IVIultiple Transport Domains - Roaming 

In this scenario a user, registered in Service Domain 0, is visiting Service Domain 1 and sets up a call via Service 
Domain 1. The QoSM in Service Domain 1 contacts the QoSPE in Service Domain to ascertain the service profile of 
the visiting user before proceeding to set up the call. 
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A.7 Provisioned VPN 



Service Domain 1 



Service Domain 2 




Transport Flow 
QoS Signalling 
Call Signalling 



M Configuration Instruction 

M Configuration Information 



Transport Resource 
Manager 



Figure 21 : Multiple Service Domains/Multiple Transport Domains - Provisioned VPN 
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Annex B (informative): 

Examples of IVIapping of QoS Architecture Functional 

Elements to Physical Elements 

This clause illustrates several different ways in which the functional elements defined in the present document may be 
incorporated into Network or User equipment. The table lists some of these possibilities. 

Table B.1 



Functional Element 


Physical Element 


QoSM 


H.323 Terminal, SIP client, H.323 Gatekeeper, SIP Proxy, 
Softswitch, H.323 Border Element, 3GPP CSCF 


QoSM (BC part) 


Media Gateway Controller, 3GPP MGCF 


QoSM (MC part) 


3GPP MRF, Media Gateway 


QoSPE 


H.323 Gatekeeper, SIP Proxy, SoftSwitch, 3GPP HSS 


TRM 


Router, edge router. Bandwidth Broker 


TRM proxy 


Firewall 


ICF 


Firewall, edge router 


TF 


Router, edge router 


TPE 


Policy Server 



Similarly Reference points will may be associated with physical interfaces on Network or User equipment. Some 
possibilities are listed in table B.2. 

Table B.2 



Physical Element 


Reference Points 


H.323 Terminal 


QC1,QT1 


SIP client 


QC1 , QT1 


H.323 Gatekeeper 


QC1,QC2, QT2 


SIP Proxy 


QC1 , QC2, QT2 


Softswitch 


QC1 , QC2, QT2 


H.323 Border Element 


QC2, QT2 


Media Gateway Controller 


QC2 


Media Gateway 


QT1, 


Signalling gateway 


QC2 


Router 


QI5, QT1 (e.g. for RSVP),QI4 


Firewall 


QI3, QT1 (e.g. for RSVP) 


edge router 


QI5, QI3, QT1 (e.g. for RSVP),QI4 


Policy server 


QI4 


Bandwidth broker 


QT2, QI1,QI2, QI3, QI4, QI5 


3GPP CSCF 


QC1 , QC2, QT2, 


3GPP HSS 


QS4 


3GPP MGCF 


QC2 


3GPPMRF 


QT1 
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